沿著早期搜尋程式讀下去時，看到同一個 ok 出現在不同層。單一學術資料服務的查詢失敗，會留下 ok: false；包住整段搜尋意圖流程的結果，則會回傳 ok: true，旁邊另外帶著各服務的狀態與警告。[1][2] 兩個值都沒有錯，卻回答了不同問題。

這正是把搜尋做成研究工具時容易踩到的陷阱。API 有回應、流程跑完、候選排好順序，都可以叫作「成功」；但它們不能共同證明來源適合研究題目。上一篇讓來源有了可辨認的紀錄，接下來要處理的，是每一種成功與失敗究竟發生在哪一層。

從一次呼叫拆成可診斷的階段

2026 年 6 月 14 日的搜尋核心，先把來源服務設定、請求、資料轉換與錯誤結果分開。稍後加入的搜尋意圖規劃器，會從題目整理概念與查詢，再把多次查詢送到來源服務、合併與去除重複紀錄，最後依題意重新排序。[1][2]

這裡的來源服務，指的是實際接收查詢並回傳文獻資料的外部系統；當時接了 Crossref 與 Semantic Scholar。provider configuration（來源服務設定）保存端點、等待時間、單次查詢量與必要標頭，讓請求規則不必散落在搜尋函式裡。[1]

前端另有一層搜尋前檢查，依題目和報告類型整理建議關鍵詞、偏好的來源種類、常見失敗與證據需求。它使用既有規則與案例作判斷；若題目和案例差異太大，便回到一般學術搜尋指引。[1] 因此這不是能理解所有研究領域的分類器，而是送出請求前的一組可測規則。

整體資料流可整理成下圖。箭頭不是成熟度排名，而是責任的交接：前一層完成自己的工作，不代表下一層已經通過。

圖：題目經過查詢規劃、來源服務、共同格式與排序診斷後，候選仍要進入品質判斷與人工審查。

同一個 ok，不能混成一個成功

早期搜尋核心讓每個來源服務回傳自己的結果物件。以下是當時型別的原始節錄；error_type 用來區分逾時與 API 失敗，正常時則是 null：[1]

export interface SourceProviderSearchResult {
  ok: boolean;
  provider: SourceProvider;
  query: string;
  results: SourceRecord[];
  error_type: SourceSearchErrorCode | null;
  error_message: string | null;
}

這個結構讓錯誤不必只存在開發者主控台。程式可以知道是哪個來源服務、哪個查詢失敗，也能保留其他服務已取得的資料。只有所有來源服務都失敗時，較外層的簡單搜尋函式才會拋出整體錯誤；仍有一個服務成功時，便合併成功結果繼續處理。[1]

但「可以繼續」的證據來自歷史測試裡注入的假回應。測試安排一個服務回傳資料、另一個回傳錯誤，再確認成功資料沒有跟著消失。[1] 它證明的是程式契約，不是當天真的發生過某次服務降級，更不是外部服務的成功率。

搜尋意圖流程又多一層語義。它把規劃內容、查詢集合、候選、來源服務狀態和警告包在一起，最外層的 ok: true 表示流程有產出這份結果；真正的來源服務成敗仍放在 provider_status 裡。[2] 如果畫面只讀最外層的值，就會把「工作流程完成」誤寫成「研究搜尋成功」。

Planner 把題目編成可執行查詢

planner 在這裡是查詢規劃器。它把題目拆成主要概念、情境、結果、研究對象，以及必須出現或應降低權重的詞，再建立中英文查詢。它也會把高精確度查詢、一般查詢與較寬的查詢分開，依順序取用。[2]

規劃器可以呼叫語言模型取得結構化計畫；沒有設定、回應格式不符、逾時或服務失敗時，則回到規則式計畫，並留下 fallbackUsed 與規劃狀態。[2] 這個 fallback（備援路徑）的價值，不是保證替代計畫一樣好，而是避免上游失敗被藏起來，讓後面還能判斷目前使用的是哪一種規劃結果。

當時的測試用幾組固定題目檢查規則，例如要求校園熱環境的查詢保留熱、溫度與微氣候等概念，不要只剩學生與學習；也用假回應測試語言模型規劃失敗後的備援。[2] 這些例子證明指定規則能被重現，不能延伸為任意題目都已規劃正確。

Reranking 只調整檢查順序

取得多批候選後，程式會先去除重複紀錄，再做 reranking，也就是依題意重新排序。當時的分數來自標題與摘要是否命中主要、必要、情境及結果詞，也參考 DOI、摘要和年份是否存在；缺少必要概念或只命中低權重詞時則扣分。[2]

這種分數很適合回答「先看哪一筆」。它能把明顯貼近題目的候選排前面，並在除錯資料裡留下命中詞與扣分原因。可是，標題與摘要命中關鍵詞，不會自動告訴我研究方法是否合適、結果能否支持報告句子，或全文是否可供核對。

因此排序不能替來源背書。歷史測試安排了刻意設計的候選，確認校園熱環境研究排在一般學習表現內容之前。[2] 這是固定資料上的排序規則驗證，不是相關性分數已成為研究正確率，也不是候選已被人工接受。

品質判斷是下一道邊界

到了 6 月 17 日，歷史程式陸續加入相關性判斷、來源權威與語言處理，以及生成準備度。相關性模組會保存命中的核心概念、缺少的概念、原因與是否建議接受；缺摘要的候選即使主題相關，也會被標成需要先查看原文。[3]

這比只看排序往前一步，因為下游開始有理由停下來。不過，規則仍主要讀取標題、摘要與中繼資料，模組之間也還沒有一個統一的最終證據決策者。[3] 本篇能說的是品質邊界開始形成，不能把後來才完成的集中判定倒寫回來。

這個階段也讓我更清楚：搜尋結果是候選，不是報告材料。來源服務回應、共同格式、排序結果與品質建議，各自都只是一次狀態轉換。只有保留它們的邊界，才知道錯誤該修查詢、來源服務、排序規則，還是後面的審查。

用第一個無法證明的階段定位問題

如果自己的搜尋功能產出不理想，我現在不會先問「API 有沒有成功」。我會由前往後核對：題目是否被編成合適查詢？各來源服務回了什麼狀態？資料是否成功轉成共同格式？排序理由能否解釋？目前第一個無法證明正確的階段，就是優先調查的位置。

這個方法不要求把所有診斷內容公開給讀者，也不需要把每個警告都寫成系統錯誤。重點是內部不要只剩一個成功布林值，畫面也不要把部分結果包裝成完整搜尋。能繼續時保留缺口，必須停止時說出是哪一層沒有條件往下走。

搜尋成為可診斷流程後，候選仍需要有人決定能不能被使用。下一篇會把鏡頭放到 accepted source：一筆資料被接受之後，下游如何只沿著已審查的方向前進，而不把被拒絕的來源重新撿回來。

參考資料

1. ResearchForge 專案 Git 歷史，〈feat: add resilient source search core〉中的來源服務設定、結構化失敗、部分結果處理、搜尋前檢查與測試。本文只引用程式契約與固定測試，不宣稱當時完成線上服務可靠度驗收。
2. ResearchForge 專案 Git 歷史，〈feat: add search intent planner and reranking〉中的查詢規劃、規則備援、來源服務狀態、重新排序與測試。本文不把測試題目或分數當成一般化研究結果。
3. ResearchForge 專案 Git 歷史，2026 年 6 月 17 日的來源相關性與生成準備度修改。用於核對品質邊界開始形成；不將早期規則提升為後來的統一證據判定。